1. Field
The present invention relates generally to distributed file systems and protocols and, more specifically, to limiting request propagation in peer to peer media sharing systems.
2. Description
There are at least several peer to peer media sharing systems in current use on computer networks such as the Internet. Napster™ is a popular system that accepts requests for specified data at a central server and identifies to the requester where on the network the specified data may be located. Due to its centralized control scheme, the Napster system does not propagate requests through the network. Gnutella™ and FreeNet™, in contrast, are systems that propagate requests for data through the network from peer to peer in a decentralized manner.
One drawback to such a peer to peer system architecture is that requests may be propagated farther through the network than are necessary to satisfy the request. Each request that is propagated at least one “hop” from one network node to another network node that is not needed consumes valuable network resources unnecessarily. To combat this problem, network designers typically implement a “time-to-live” feature encoded in requests for data. For example, a constant time-to-live value is used in several network protocols, such as Internet Protocol (IP), to prevent swamping of the network by request packets. The time-to-live value is checked during propagation of request packets by each network node and the request is forwarded along to the next hop in the network only if the time-to-live value is not yet exceeded. When the time-to-live value is exceeded, the request is considered “dead” and no longer forwarded.
Gnutella and FreeNet both implement a time-to-live feature in their requests. However, neither of these systems have a way to intelligently limit the time-to-live value, because neither system can know the maximum distance in the network between the requester and the data being requested. In these systems, any network node is just as likely as any other network node to contain the data being requested. Thus, both of these systems set the time-to-live value to a relatively high constant value (e.g., 20 or 25 network hops). This results in many instances of wasted network bandwidth due to forwarding data requests unnecessarily.